home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Gigarom 1
/
Gigarom Macintosh Archives (Quantum Leap)(CDRM1080320)(1993).iso
/
FILES
/
HYP
/
H-I
/
HyperHackers.cpt
/
Hyper-Hackers Queue 1.0
/
card_33922.txt
< prev
next >
Wrap
Text File
|
1989-02-26
|
2KB
|
65 lines
-- card: 33922 from stack: in.0
-- bmap block id: 0
-- flags: 0000
-- background id: 3797
-- name:
-- part contents for background part 1
----- text -----
From: ns@CAT.CMU.EDU (Nicholas Spies)
Date: 8 Mar 88 16:04:38 GMT
Is there any way to determine whether the contents of a field can be
evaluated as a numeric expression (with "the value") without having it
put up a dialog when the value can't be calculated? It would be nice to
be able to let scripts deal with such cases if "the result" returned "Not
a value".
This might be handled by letting the HyperTalk programmer set system state
variables to change default system actions within a handler, much as "set
lockscreen to xx" works now. Giving commands properties that would reset
to the default behavior between handlers would seem to offer a means to
add new features at will while retaining compatability with current stacks.
Begin able to say
set reportError of value to false
to turn off its default dialog response within a handler would allow much
flexibility while retaining readable code.
Imagine also being able to say
set delimiter of word to ";" - or anything else
for parsing or
set select of find to true
to cause find to leave what it found in "the selection" rather than just
highliting with a frame. Or how about
set single of line to true
to cause "the line" to return one line of text rather than text to the next
carriage return. (This actually might be better as a settable property of
text fields). Or how about
set fullLine of sort to true
to cause sort to base its action on a full line of text rather than
obligating the programmer to concatenate strings to get this effect.
The alternative to this or some comparable means of extending HyperTalk is
the chaos of having to write or depend on home-built XCMDs and XFNCs of
unknown reliability. (Speaking of this, does Apple have any plans for
creating a library of XCMDs and XFNCs; it would seem to be at least as
important as the registration of font names...)
-- part contents for background part 45
----- text -----
Re: the target